1. Field of the Invention
This invention relates to a method and apparatus for managing contention among users for access to serialized resources in an information handling system. More particularly, it relates to a method and apparatus for managing such contention in a system cluster containing a plurality of such systems.
2. Description of the Related Art
Resource contention is a well-known phenomenon in information handling systems. It occurs when a user (e.g., a process or other unit of work) attempts to access a resource that is already held by another user, and the access requested by the second user is inconsistent with that of the first user. This will occur, for example, if either user is requesting exclusive access to the resource in question. Resource managers are software components that manage contention among competing requesters for a resource that they control by granting one or more such users access to the resource as a holder and placing any remaining users in a pool of waiters until the resource becomes available.
In a computer operating system such as the IBM z/OS™ operating system, with multiple resource managers and multiple units of work, resource contention management is a complex problem.
Contention chains can form, or put another way, contention can cross resources. For example, job A waits on resource R1 but holds R2, while job B holds R1 but is waiting for R3, which in turn is held by job C. Contention can cross systems. In the example above, each job could be on a separate system. Contention can cross resource managers. For example, R1 could be a GRS enqueue and R2 could be a DB2™ latch. The global resource serialization (GRS) component of z/OS manages enqueues, while the IMS™ Resource Lock Manager (IRLM) manages the DB2 resources separately.
Cross-resource contention is typically solved within a single resource manager (e.g. GRS) by tracking the topology of each resource's holders and waiters and finding any points of intersection. Cross-system contention is typically solved by making the resource manager aware of the entire cluster's data (managing the cluster as one unit rather than as independent systems). Cross-resource manager contention is typically “solved” by having a reporting product query all of the interfaces and correlate the data as if it were a virtual resource manager. Because the problem is of order O(2n) in the number of resources in contention, it is also computationally complex.
The base MVS™ component of z/OS has a simple efficiency solution (known popularly as “enqueue promotion”): automatically (and temporarily) boost the CPU and MPL access of any work holding a resource reportedly in contention, with no attention paid to the neediness of the work. This is equivalent to managing a holder as if there were “important” waiter(s) for a resource, regardless of the actual topology. To appreciate the operation of this, consider the following example. Suppose that:    1. Job A holds resource R1.    2. Job B holds resource R2 and waits for R1.    3. Job C waits for R2.
Notationally, this can be represented as a chain C→B→A, where the capital letters represent the jobs, and the symbol “→” (the “link” in the chain) indicates that the job on the left of the symbol is waiting for a resource held by the job on the right of the symbol. Thus, the above chain means that job C is waiting for a resource held by job B, which in turn is waiting for a resource held by job A.
Assuming these are GRS resources, the conventional MVS implementation would help jobs A and B because they hold resources under contention, promoting each equally and for a limited time. Helping B would do no good, however, since B is in fact waiting for A. If B is itself multitasking, then the help may actually harm competing work without doing anything about the resource contention.